👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labeled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

Taking a step back — the goal here is great. External contributors need to be able to run acceptance tests without maintainers doing it manually. But I think we're building a lot of custom machinery (fork detection, label gates, secret validation, untrusted environments) to solve a problem GitHub already solves natively.

Environment protection rules with required reviewers replace almost all of this:

• Workflow triggers on fork PRs normally
• Job references an environment with "required reviewers" enabled
• Workflow pauses and waits for a maintainer to click "Approve"
• Only then do secrets get injected and tests run
• New commits on the PR = new deployment = automatically requires re-approval

That last point is critical. The label-based approach has a gap where an attacker can push new commits after the acctest label is applied, and tests re-run without re-review. Environment protection rules close that gap by design.

It also eliminates the interaction risk with things like AI-powered labelers (#3272) — if an automated tool accidentally applies acctest to a fork PR, tests run with secrets and no human ever reviewed the code. With environment protection rules, labels aren't a security boundary at all.

The simplified workflow would look something like:

on:
  pull_request:
  push:
    branches: [main, release-v*]

jobs:
  test:
    runs-on: ubuntu-latest
    environment: acctest-dotcom  # required reviewer gate handles everything
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
      - run: go test ./github -v -count=1 -parallel=20 -timeout=30m
        env:
          TF_ACC: "1"
          GITHUB_TOKEN: ${{ secrets.GH_TEST_TOKEN }}
          # ... other test vars

The entire setup job, fork detection, label check, and secret validation step can go away. GitHub's native environment protection is purpose-built for exactly this use case — gating secret access behind human approval on a per-run basis.

I quickly looked into some of the test failures:

• The App is lacking permissions for Codespaces secrets(?) or just Codespaces in general
• The App is lacking permission to read Org IP Allowlist
• "Deploy keys are disabled for this repository" sounds like the Org has disabled Deploy keys?
• The test run ran longer than 60min => App Token invalid?
• TestAccGithubActionsOrganizationWorkflowPermissions is failing due to trying to modify values disabled by Enterprise
• TestAccGithubActionsRunnerGroup should maybe ignore etag in import test